Transaction processing systems have led the way for many ideas in distributed computing and fault-tolerant computing. For example, transaction processing systems have introduced distributed data for reliability, availability, and performance, and fault tolerant storage and processes, in addition to contributing to a client-server model and remote procedure call for distributed computation. Importantly, transaction processing introduced the concept of transaction ACID properties—atomicity, consistency, isolation and durability that has emerged as a unifying concept for distributed computations. Atomicity refers to a transaction's change to a state of an overall system happening all at once or not at all. Consistency refers to a transaction being a correct transformation of the system state and essentially means that the transaction is a correct program. Although transactions execute concurrently, isolation ensures that transactions appear to execute before or after another transaction because intermediate states of transactions are not visible to other transactions (e.g., locked during execution). Durability refers to once a transaction completes successfully (commits) its activities or its changes to the state become permanent and survive failures.
Many applications for workflow tools are internal to a business or organization. With the advent of networked computers and modems, computer systems at remote locations can now easily communicate with one another. This allows computer system workflow applications to be used between remote facilities within a company. Workflow applications can also be of particular utility in processing business transactions between different companies. Automating such processes can result in significant improvements in efficiency, not otherwise possible. However, this inter-company application of workflow technology requires co-operation of the companies and proper interfacing of the individual company's existing computer systems.
A fundamental concept of workflow analysis is that many business processes can be interpreted as a sequence of basic transactions called workflows. Workflows have a customer, a performer, and conditions of satisfaction. The customer and performer are roles that participants can take in workflows. In addition, workflows can have observers. In conventional business workflow systems, a transaction comprises a sequence of operations that change recoverable resources and data from one consistent state into another, and if a failure occurs before the transaction reaches normal termination those updates will be rolled back or undone. ACID transactions control concurrency by isolating atomic transitions against each other to create a serializable schedule by delaying updates until committing of transactions. This isolation limits granularity viewed by an observer to the size of the parent transactions until all child transactions commit within a parent transaction. Therefore, application specific programs cannot be invoked and monitoring of transactions by users cannot be performed based on any actions occurring within a transaction, until the transaction fails or commits.
The Unified Modeling Language (UML) defines a standard notation for representing flow charts for business workflow processes. However, the UML notation cannot be reduced to a programming language for employing complicated workflow processes. Current business workflow software systems provide scheduling software that requires binding within the scheduling to couple the schedule to real world applications and technologies. Conventional schedules require code to couple the components of the schedule to application program interface (API) objects and/or server objects for interfacing the schedule with systems within each business or department involved in the business process. These types of schedule software require sophisticated programmers to implement the software for a given business workflow model. Furthermore, these types of schedule software require modification of each schedule for different technologies.
Accordingly, there is an unmet need in the art for a system and/or method for providing a software tool for modeling a business workflow process that mitigates some of the aforementioned deficiencies associated with conventional software and modeling of business workflow processes.